home *** CD-ROM | disk | FTP | other *** search
- Path: news.iadfw.net!usenet
- From: Larry Weiss <lfw@iadfw.net>
- Newsgroups: comp.lang.c
- Subject: Re: 'Freeing' storage with realloc
- Date: Sat, 17 Feb 1996 21:06:27 -0600
- Organization: ---
- Message-ID: <312697B3.618E@iadfw.net>
- References: <4fv44f$p2v@news.rz.uni-passau.de> <824596026snz@genesis.demon.co.uk>
- NNTP-Posting-Host: dal26-27.ppp.iadfw.net
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0b6a (Win16; I)
- CC: lfw@oc.com
-
- Lawrence Kirby wrote:
- >
- > In article <4fv44f$p2v@news.rz.uni-passau.de>
- > berndl@sidonius.uni-passau.de "Klaus Berndl" writes:
- > ... Does realloc 'freeing' the storage behind byte 13?
- >
- > The extra storage is in principle if not in practice freed. All that is
- > important as far as the program is concerned is that it is illegal to
- > access buf[13] or beyond after the realloc. Whether a particular
- > implementation leaves the storage in place is up to the implementation
- > although any reasonable implementation will make the space available for
- > further allocation where possible. If you still need to use the space as
- > part of that array then that call to realloc is inappropriate and should
- > be removed or changed to a more suitable value.
- >
-
- Also, library functions also are allowed to allocate dynamic memory as they
- see fit. Therefore, for several reasons it is not possible to assume that,
- say, if one successfully malloc()'d 1000 bytes and the free()'d them, that
- you are guaranteed to be able to malloc() those 1000 bytes later, even though
- your code didn't explicitly allocate any space in the interim.
-
- You may malloc() a pool of memory early on, and manage it yourself if you want
- more control, but that should be obvious.
-